Subject: Re: CG: UML critique (Was: KR Book) Date: Thu, 16 Dec 1999 22:11:43 -0500 From: sowa@west.poly.edu (John F. Sowa) Reply-To: cg@cs.uah.edu To: cg@cs.uah.edu Graham, I was going over my backlog of email, and I found that I hadn't responded to this one. Since it's over 2 months old, let me just make a couple of quick points: 1. I have nothing against UML as a collection of diagramming techniques to support O-O design methodologies. I think that it should be quite useful for many purposes. 2. My major complaint is that they don't take advantage of logic to provide a unifying framework for all the diagrams. In fact, they do have a home-grown notation for predicate calculus called OCL (object-constraint language), but the textbooks on UML ignore it. 3. As I mention in the KR book, there is potentially an infinite number of diagramming techniques that could be developed to support different aspects of knowledge representation. I would prefer to see a system such as UML based on an extensible mechanism for defining an open ended number of diagramming techniques and relating them all to logic. 4. That is one of the design goals for conceptual graphs: define the abstract syntax in a form that is completely independent of any notation whatever; offer a few convenient notations such as the display form, the linear form, and CG interchange form. But then anyone who prefers any other form can call it a CG representation as long as it has a direct mapping to the abstract syntax. For example, the concept [Chicken] could be displayed as a picture of a chicken, the nodes and arcs could be represented in 3-D virtual reality, a concept of an action could show a movie of the action, etc. To answer people who think that logic is unreadable, I would recommend controlled English, as described in Ch 7 and Appendix C of the KR book. For convenience, I put some of that material on-line with hypertext links to other supporting material: http://www.bestweb.net/~sowa/misc/ace.htm John Sowa ======================================================================== To post a message, send mail to cg@cs.uah.edu. To unsubscribe, send mail to majordomo@cs.uah.edu with the command 'unsubscribe cg' in the message body. ======================================================================== For help or administrative assistance, mail to owner-cg@cs.uah.edu ubject: Re: CG: UML critique (Was: KR Book) Date: Fri, 17 Dec 1999 19:19:51 +0700 From: "Thanwadee Thanitsukkarn (Pomme)" Reply-To: cg@cs.uah.edu To: References: 1 Hi all, > > 2. My major complaint is that they don't take advantage of logic to > provide a unifying framework for all the diagrams. In fact, they > do have a home-grown notation for predicate calculus called OCL > (object-constraint language), but the textbooks on UML ignore it. > > 3. As I mention in the KR book, there is potentially an infinite number > of diagramming techniques that could be developed to support different > aspects of knowledge representation. I would prefer to see a system > such as UML based on an extensible mechanism for defining an open > ended number of diagramming techniques and relating them all to logic. > Sorry to join the discussion on this topic late, but the above comments got me thinking about my approach. In my thesis, I have proposed to use CGs to solve the mention issues. My approach is to use CGs as a meta-representational language to describe the diagrams of UML. Accordingly, I am able to apply the logical reasoning power of CGs to automate consistency checking of software specifications generated in term of UML diagrams. For example, I use the following CGs definition of UML to check consistency in class inheritance, i.e. "circular inheritance is not allowed": relation type parent(X,Y) [class: *X] -> (parent) -> [class: *Y]. is [association] - (type) -> [generalization] (from) -> [associationEnd] <- (connection)<- [associationRole] <- (collaboration) <- [class: *x], (to) -> [associationEnd] <- (connection) <- [associationRole] <- (collaboration) <- [class: *Y]. The above CG states that a class Y is a parent of a class X if there exists a generalization association connected from the class X to the class Y. Accordingly, I define the following relation type: relation type child(X,Y) [class: *X] -> (child) -> [class: *Y] is [ [class: *Y] -> (parent) -> [class: *X] ] -> (or) -> [ [ [class: *Y] -> (parent) -> [class: *Z] ] -> (and) -> [ [class: *X] -> (child) -> [class: *Z] ] ] The above CG states that a class Y is a child of a class X if class X is a parent of a class Y or there exists a class Z which is a parent of a class Y and that class Z is a child of class X. Then, I can use the above relation type definitions to construct the inheritance rule as follow: ~ [ [ [class: *X] -> (child) -> [class: *Y] ] -> (and) -> [ [class: *Y] -> (child) -> [class: *X] ] ] which states that there must not exist any class Y which is a child of a class X and that class X is also a child of the class Y. The same construct of consistency rules can be applied to other types of UML diagrams. Therefore, I can unify the specifications represented in different UML diagrams for consistency checking. I am extending the framework for domain specific rules, i.e. those which cannot be checked by the syntax of the diagrams. If anyone is interested, the detailed examples of the work can be found at http://www-dse.doc.ic.ac.uk/~tt4/THESIS/thesis.pdf Any comments would be appreciated. best regards, Thanwadee ---------------------------------------------------------------------------- ----------------------------------------- Dr. Thanwadee Thanitsukkarn Mahidol University Computing Center | Phone: + 66 2 247 0333 ext. 210 Faculty of Science, Mahidol University | Fax: + 66 2 246 7308 Rama 6 Rd., Bangkok 10400 Thailand Email: cctth@mahidol.ac.th